home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Monster Media 1996 #15
/
Monster Media Number 15 (Monster Media)(July 1996).ISO
/
rem_acc
/
iserv260.zip
/
ISERVCFG.HLP
< prev
next >
Wrap
Text File
|
1996-04-03
|
28KB
|
699 lines
iServer 2.6 ∙ Internal Help File
──────────────────────────────────────────────────────────────────────────
This is a context sensitive help file that is intended to be used with the
ISERVCFG.EXE program, and not directly viewed with a file reader.
Please run ISERVCFG.EXE and press F1 from anywhere for detailed help.
──────────────────────────────────────────────────────────────────────────
Press Ctrl-C to abort...
[]IRS
With iServer you can make your system automatically respond to messages
addressed to certain functions. They can be very powerful for responding
to queries or running programs much like an automated full internet server.
For example, you could have an entry setup that when someone posted a
message to "help@yoursite.com" that it returns a help file to the poster
of the message.
You can also setup a function to respond to a message automatically with
a text file, but then also leave the message to the receiver, rather than
delete it. For example, you could have "comments@yoursite.com" that would
send a "thank you for your comments" text file immediately, but then leave
the comments for you to review later.
You can also run programs on demand, for example you could setup an
entry that when someone posted to "add-to-faq@yoursite.com", that it
would run a program that could take their original message, and add it
to another text file.
When a program is shelled from iServer, it will create a file called
"REQUEST", this file will contain all the info about who the message
was from, to, subject, etc, along with the original text of the message.
When the shelled program returns, iServer will check for the existance
of a file called "RESPONSE", if it exists it will be posted back to
the original sender of the request.
For example:
User posts to "add-to-faq@yoursite.com" you could run a program,
even a batch file, like this:
@echo off
type REQUEST >> \THEFAQ.TXT
copy THANKYOU.TXT RESPONSE
This would copy the original message into a growing text file, and
send them back a "thank you" message.
Another example:
You can get iServer to run other maintenance or utility programs
when it sees messages to another user. For example, if you are
using Transx, you could get iServer to watch for messages to
"transx@yoursite.com" and run TRANSX.EXE when it saw an incoming
message for that program.
There is one last function type, that allows a message to trigger
another program to run after it. For example, you could setup
iServer so if it saw a message to "AreaFix", it would run your
areafix manager after it was done. The reason that you would want
to run it after iServer is completed rather than right away, is
to avoid any sharing problems between the two applications
scanning the same netmail message area.
With these four options of the response function, you can automate
basically any part of your system with lots of infobots and custom
run-on-demand programs.
In addition, you can govern the format of the "REQUEST" file by
editing the "RESPOND.MSG" file in your iServer directory.
Limited to 3 responds in unregistered version.
[]RPE
When people post your system at "someone@yoursite.com", the "someone"
part is called a "Trigger", you can setup some automated features or
information packages on what are called "Infobots" What the Infobot
does is dependant on the "Type" that you have specified.
Trigger
■ This is the trigger part of the name that you want to use for
your automated feature.
Type
■ You have four different types of Infobots available:
Return message This returns a textfile as a message to the sender
of the infobot request then deletes the original
message received.
Reply and forward This returns a textfile as a message to the sender
of the infobot request and leaves the original
message present.
Run program This creates a template file called "REQUEST" in the
iServer directory that contains information about the
sender of the message, it then executes an external
program, and upon returning, if there is a file
called "RESPONSE" it will post that to the sender of
the original message. The original message is
deleted in this process.
Delay Run Program This is causes the external program to be run after
iServer has completed scanning the netmail directory.
iServer does not deleate the trigger message at this
time, and leaves that upto the called program to do
after it has finished processing it.
File
■ This is either the textfile name to send to the requester, or if the
Type is "Run", it is the program to execute.
Subject
■ Whatever is in here will replace the old subject on any returned
messages. If it is blank, the original subject will be used when
creating the reply.
For example, if someone posted a message:
To: triggername (the @yoursite.com is removed at the gateway)
Fm: bobuser@elsewhere.com (the requester of the information)
Sb: Info please (the original subject)
And you had a trigger called "triggername", that returned a textfile
and replaced the subject with "Your request", you would see the headers
of the new message look something like this:
To: bobuser@elsewhere.com (the requester of the information)
Fm: servername (the @yoursite.com is added at the gateway)
Sb: Your request (the new subject replaced)
This feature is great for setting up information services, such as:
help@yoursite.com
comments@yoursite.com
info@yoursite.com
prices@yoursite.com
Limited to 3 responds in unregistered version.
[]T
Tables are much like "Infobots" in the fact that they can return,
forward or execute programs when triggered. The difference is that
instead of looking for a "triggername@yoursite.com", iServer can
scan "Tables" of names to search for a match.
Its main purpose is to be able to put userid names into classes of
functions. For example, say you had a number of users that abused
your system, and you did not want to accept mail for them, you could
simply put all of their names into a table, and have any mail that
came in searched against that table. If there was a match, you could
return the mail to the sender.
Here's the setup for the above example:
Table : BADUSERS
Type : Return
File : \path\BADUSER.TXT
Now anytime a message came in that was addressed to a user that was
in the BADUSERS table, it would return a textfile "BADUSER.TXT" to
the sender of the message.
To put user names into a table, use the included program "TABLE.EXE"
The usage for TABLE.EXE is as follows:
TABLE <tablename> <+|-><username>
For example to add the user "Bob User" to the BADUSERS table, you
would type: TABLE BADUSERS +Bob User
To remove Joe Smith from the same table, you would use this command
line instead: TABLE BADUSERS -Joe Smith
Another idea for a table is having a vacation notice. You could
have "TABLE.EXE VACATION +User name" as an option from your BBS as
a "run an external program menu option". The user could run it to
put themselves on a "vacation list", then you'd have a table entry
like this:
Table : VACATION
Type : Reply and Forward
File : \path\VACATION.TXT
This would return a message to the sender letting them know that
the receiver might be a while before responding, and because the
Type is "Reply and Forward", the original message will be left for
them when they return.
Registered use only.
[]TE
Table
■ This is the name of the table file to scan. It will be located in
your main iServer directory with a .TBL extension.
Type
■ You have three different types of Infobots available:
Return message This returns a textfile as a message to the sender
of the infobot request then deletes the original
message received.
Reply and forward This returns a textfile as a message to the sender
of the infobot request and leaves the original
message present.
Run program This creates a template file called "REQUEST" in the
iServer directory that contains information about the
sender of the message, it then executes an external
program, and upon returning, if there is a file
called "RESPONSE" it will post that to the sender of
the original message. The original message is
deleted in this process.
File
■ This is either the textfile name to send to the requester, or if the
Type is "Run", it is the program to execute.
Registered use only.
[]RTE
Restrict
■ This is the site or function that you want to restrict. It will be
searched for in the destination address, as well as the subject.
■ Partial matches are also found, therefore restricting "SUBSC" also
restricts "SUBSCRIBE", etc..
Flag override
■ If you wish users with a certain flag to be able to access this site
still, you can do so by placing the flag required here. This is great
for allowing certain users access to certain sites while restricting
others from posting to it.
■ To erase a flag that is already set, simply replace the flag with
spaces and hit enter.
Limited to 3 restricts in unregistered version.
[]ME
Trigger
■ This is the name you want to trigger on. It must be exactly the
way the messages arrive at your system.
Trigger on
■ This can be "To" or "From". For "To", it means that you want to
look at who the message is to, and if it matches, consider the message
to be destined for the public base.
■ Note that for inbound messages, your domain name is not included, for
example if you subscribed to a mailing list from the account name
"ml1@yoursite.com" the trigger should be "ml1" if using the "To" method.
■ If all the messages come "From" a specific user, you can use the second
method, and look at who the message is from. For example, if all the
messages were posted from "list-owner@remotesite.com", you would put
that full name as the Trigger.
For example:
From : mcc-owner@uti.com
To : fakename
Basename
■ This is the path of the public base that the mail should be merged
into. Currently only JAM is supported, and the format should follow
the same as the main message base path.
Outbound
■ This parameter controls whether or not the mail base will be scanned
for outgoing messages. This is good for news letters and other such
lists that you do not want users being able to reply to. You can of
course specify the area as Read-Only in your BBS setup (suggested) but
by selecting this here, iServer will bypass the scanning of this area,
thus increasing processing speed.
■ If you do allow replies, any found will be exported as standard
internet email.
[]M
Another great feature of iServer, is its ability to take mailing lists
and merge them into a public reading base. This is great if you want
to subscribe to a popular mailing list, and make it available to all
your users without them all having to subscribe to it themselves, and
receiving multiple copies of the same messages.
You could subscribe to the mailing list with a psuedo-name, and use
this merge function to detect mail to this psuedo-name and import
it into the public base.
For example: 1) Subscribe to a list using a fake user name
"ml1@yoursite.com"
2) Mail comes into "ml1" and merge sees it and
imports it into a public base you define.
More information regarding the field setup in merge is available
by pressing "Insert" to insert a new merge, and then pressing "F1"
for help on the field options.
[]RS
This is one of the most powerful features of iServer that will allow
you to setup subscription levels, or simply restrict access to certain
functions if your gateway is long distance, or does not accept certain
types of functions or requests.
Any outgoing messages that have any of the names listed in the restrict
section or any partial matches thereof in "to" address or the first word
in the subject line, will be considered to be restricted. You may
override certain restricts with a user flag if you wish.
Example: SUBSC A2 (Restricts "SUBSC" unless user has flag A2)
LISTSERV A2 (Restricts "LISTSERV" unless user has flag A2)
FTP (Restricts "FTP" always)
Since you can use a flag to override certain sites, it is excellent as
a tool to help promote finacial support of your internet email services.
Limited to 3 restricts in unregistered version.
[]I
Messages addressed to "ignored" names will remain in the netmail folder
as if iServer had never seen them. It is good for leaving requests
upto other programs, or if you wish your personal mail to be leave in
your netmail folder, you can place your name in an "ignore".
Example: ALLFIX
AREAFIX
PETE ROCCA
[]A
By default, encodeded files (such as UUENCODE, BASE64, MIME, etc) are
bounced when attempting to be exported, however you can override this
for certain users or users with certain flags, or disable the
restrictions for all users, using any of the following 3 methods.
Example: PETE ROCCA
A2
ALL
This would allow "PETE ROCCA", users with flag "A2", or "ALL" users,
respectively, to post encoded files. You can use a combination of
these settings to tailor the restrictions to exactly your requirements.
[]UE
One of the nice features of iServer, is that it allows your users to
change their handle on the BBS to something that is more appropriate
for internet email addresses. For example, the user "Pete Rocca" might
change his handle to "rocca"
What is special about allowing iServer to do it, instead of your BBS
is that it allows you to restrict certain handles from being used, as
well as giving you the option to only allow users to change it once,
since if the user is constantly changing their address, all the mail
to their old address will be returned to sender since the old name no
longer exists on your system.
Userid selected flag
■ This is the flag that you wish to have turned on once the user has
selected an alias.
Min userid length
■ This is the minimum number of characters allowed in the userid.
Max userid length
■ This is the maximum number of characters allowed in the userid.
Bad handles
■ This is a list of names or partial names that you do not want users
to be able to select. The list is partially matched, so an entry
of "ROOT" would also restrict "ROOTED", "DEROOT", etc..
Some good defaults include:
ROOT POSTMASTER WWW
ADMIN SYSOP FTP
Once you have these options set, and you wish to allow your users
to use the handle option, you should present them with an option
to run ISERVER with the parameters "/USERID c:\path_to_dropfiles"
For example you would make menu option to shell:
C:\ISERVER\ISERVER.EXE /USERID C:\RA
If you do use this option, don't forget to set the Internet email
area on your BBS to use "Handles" instead of "Real names"...
Also, a good way to run it so that it gets run only once, is to make
a menu option that is "Autoexecute=Yes" with the "Not flag" of whatever
flag you are to have set, that way if a user does not have the flag
set, it will run the "ISERVER.EXE /USERID" program automatically.
[]SA
Normally you would only process messages to your site address you are
using for your email, however if you wish to utilize some of the other
features in iServer, such as InfoBots and message bouncing for your
other addresses, you can list those akas that you wish iServer to process.
[]PL
If you are using the USERS.BBS type of userbase, then you can restrict
the number of messages a user below a certain security level can post
in a give period. iServer will keep a record of these posts in the
LIMIT.DAT file which is located in the iServer directory, once a user
exceeds the number of messages in this database, their messages are
bounced back with the LIMIT.BAD template file.
When you wish to reset the counters, simply delete the LIMIT.DAT file.
For example, if you wanted to restrict users to a single message a day
you would specify "1" for the number of posts to restrict, and then
delete this file in your midnight maintenance. Likewise, if you wanted
to restrict to 100 messages a month, you would specify "100" and delete
the LIMIT.DAT file in your monthly maintenance.
If you do not wish to restrict any users, simply leave the values at
zero, and iServer will not use the limiting features.
[]MRM
Sometimes it is desired to remap one address to another, such as mapping
a fake account "postmaster@yoursite.com" to "sysop@yoursite.com", this
way you can provide a generic userid and have it mapped into another
account, without having to create and maintain a special account on the
BBS for the original name.
You might also use this function to remap commonly misspelled versions
of your own name, or multiple accounts you might want to have presented
as valid.
Some examples...
Remap mailbox: POSTMASTER -> SYSOP
Remap mailbox: PETER ROCCA -> PETE ROCCA
Remap mailbox: ROCCAP -> PETE ROCCA
[]GI
Domain
■ This is your domain name. If you are feeding from a private gateway,
your gateway will assign you a name. If you are feeding from your zone
fidonet gateway then your domain is as such:
f<node>.n<net>.z<zone>.fidonet.org
For example, if your Site Address was 1:2401/305, your domain would be
f305.n2401.z1.fidonet.org
If your address has a point, simply preceed the address with p<point>
for example 1:2401/305.10 would be p10.f305.n2401.z1.fidonet.org
Server Name
■ This option allows you to specify what name the server will use to
bounce messages, and for response functions.
■ It is only cosmetic, so what you choose is not extreamly important,
however some good suggestions are:
mail-daemon
mail-server
server
Site Address
■ This is the fidonet address that you will be receiving the internet
email to. For basic setups, this will be your main fidonet address,
however see the documentation on how to setup an optimal system that
will not conflict with your regular netmail.
Uucp Address
■ This is the fidonet address of your gateway that will handle the
email for you. If you are using the free zone 1 gateway then the
address should be 1:1/31, however if you are using a private gateway,
you should ask your gateway what address to put in here.
Uucp Secondary
■ Most people will not need this function. What it does is allow you
to have to inbound UUCP feeds merged into the same email stream. For
example if you had two feeds you could place the fidonet address of
the secondary feed here and have both of them converge in the same email
base.
■ It should be noted that all outbound mail will be destined to the
main Uucp Address.
Serial & Registration
■ This is where you place the serial and registration codes once you have
registered iServer.
[]ARM
Sometimes it is desirable to remap mail going from one address to another.
This is good if you have users manually posting netmail to an incorrect
gateway that you would like redirected.
Some examples...
Remap address: 1:1/31 -> 1:2401/305.1000
Remap mailbox: 1:2235/10.999 -> 1:2401/305.1000
You can also use it to redirect other kinds of mail, perhaps you have
two fidonet addresses, but would like them to converge into one area.
[]SO
Import mail to all@yoursite.com
■ If you wish to have mail that is addressed to all@yoursite.com imported
into the internet email base with the public flag, rather than have the
mail returned to sender then set this option to "Yes"
Convert "site!user" to "user@site"
■ Some UUCP providers will send you mail that looks like it's
backwards. If it looks like "site.com!user" instead of "user@site.com",
you may switch it around to the more preferred addressing method.
Delete fidonet information
■ If your email messages contain information in the fidonet control
lines, and you do not wish them to be imported into the BBS, you
can disable it with this function.
■ Some have reported that ProBoard locks up when importing large
JAM kludges into the board, if this happens to you, you should
consider deleting the fidonet information.
Retry underbars with periods
■ Some gateways incorrectly remap email -> user names by inserting
underbars in names rather than periods. If your gateway does this
and you want to increase the chance of mail being imported to the
user correctly, select "Yes".
For example the gateway might map:
pete_rocca@mbcc.com instead of
pete.rocca@mbcc.com
With this option on, iServer will try both variations to see if the
user exists.
Cache tables at startup
■ If you are using "Tables" that you have setup in the Advanced Setup
section, you can have the option to cache them at startup.
■ If you do not have very many table hits, it is a good idea to leave
this off, however if you use the tables a lot, caching at startup
will make iServer run much quicker.
Convert outbound addresses to lowercase
■ If you wish, you can convert all outbound addresses to be converted
to lowercase. For example "USER@SITE.COM" would be coverted to
"user@site.com" This is usually a cosmetic preference option.
Set the "Keep/Sent" flag on netmail
■ When posting the outbound netmail, you can have the option to set
the "Keep/Sent" flag. Usually most will have this option turned off.
Set the "Direct" flag on netmail
■ When posting the outbound netmail, you can have the option to set
the "Direct" flag, this is usually best left on unless you are
routing your mail to your provider (ie 1:1/31)
Check for dumb outbound messages
■ iServer can check for outbound messages that are not addressed to
a valid name, even before they leave your site. Addresses that do not
have the "@" or "!" symbol cannot be processed by most gateways, so
rather than sending this mail to the gateway, iServer can bounce it
back to the user immediately.
Always export "UUCP" in header
■ By default iServer attempts to put the destination address into
the netmail "To" header. If it cannot fit, it addresses the message
"To: UUCP" and puts the address on the first line.
■ If you wish to always use the "To: UUCP" method, you can do so by
selecting this option.
Delete mail from base once exported
■ Once iServer exports the message, it marks it as "sent" so it will not
need to be processed again, however it leaves the message in the
message base as many people like to be able to see what messages they
have sent. If you wish to remove the message from the BBS immediately
after processing it, select "Yes"
[]FPC
Netmail path
■ This is the path to the netmail folder that your mailer uses for
its *.MSG files.
User base
■ This is the filename of the file that stores all of the user
information. There are two Types available; RA and Text. For RA
it is the full path and filename of your USERS.BBS file. For text,
it is the path and filename of an ASCII text file containing valid
user names.
Message base
■ This is the full path and filename of the path of the message base
on the BBS. Right now only JAM is supported, other formats will soon
follow, including PCBoard.
Example: C:\MAIL\JAM\EMAIL Type:JAM
Would use the JAM base that created:
C:\MAIL\JAM\EMAIL.JDT
C:\MAIL\JAM\EMAIL.JDX
C:\MAIL\JAM\EMAIL.JHR
C:\MAIL\JAM\EMAIL.JLR
Log file
■ This is the name of the logfile that iServer will use to log mail
traffic and events. If you do not wish to use a log file, put NUL
for the filename.
Update semaphore
■ When iServer modifies the netmail folder, it can notify other tasks
to rescan the folder to see the changes. Depending on what mailer
you are using these file names will change.
■ For FrontDoor the names of the files are FDRESCAN.NOW and FMRESCAN.NOW
and are located in your FD semaphore directory.
Example: C:\FD\FDRESCAN.NOW
C:\FD\FMRESCAN.NOW
Consult your mailer documentation for the correct semaphore file names
for you to use.
[]EXIT
This allows you to exit the configuration program. If you have made any
changes, it will prompt you to save any changes before exiting back to
the system prompt.
[]MAIN
┌──iServer───────────────────────────────────────────────────────────────┐
└────────────────────────────────────────────────────────────────────────┘
What does it do?
■ iServer will import email from a fidonet netmail format directly
into your RemoteAccess system as internet email. No longer will
your users have to know anything about addressing to "UUCP" at some
obscure netmail address.
■ Of course, it will also export outbound mail from your BBS and
prepare then in a netmail fashion, ready to be gated out.
A complete solution!
■ iServer is not only a tosser for your mail, but a powerful server
engine as well. iServer can automatically bounce mail addressed
to unknown users on your system, or respond to inbound messages
automatically. With iServer and its request/respond system, you
can build powerful applications to interface with your basic email
system, such as info-bots, listserv and ftpmail.
■ Outbound messages can be restricted on site, or user security
settings and the number of messages posted per user. You also
have the option to restrict file transfers via email, such as
UUENCODED, BASE64 or MIME formatted messages. iServer integrates
completely and seemlessly with your BBS system, using it's data
files for user verification, as well as obtaining user security
information for its message restricting features.
Overview...
■ Seamless integration with RemoteAccess
■ Direct import/export of email
■ Powerful server response engine
■ Bounce messages to unknown users
■ Merge mailing lists as usegroups
■ Restrict certain sites, functions or encoded files
■ Custom templates for bounce messages
■ Dumb address checking
■ Disclaimer message support
■ Excellent author support
┌────────────────────────────────────────────────────────────────────────┐
└────────────────────────────────────────────────────────────────────────┘
[]